Tangoe Mobile REST API

There are two ways to connect and access Tangoe to leverage client data that cover most mobile needs. It is important to understand that Procurement and Support Requests are handled separately. Procurement and Change Management ( order request ) fall under Activity Requirements & Suggested Lookups where mobile related issues fall under Support Request. Inventory is a PULL on a frequency that works for the client or a scheduled .csv file drop to an SFTP location.

Use Cases

1. Procurement and Change Management (orders)
2. Inventory (asset management)
3. Support Request (mobile-related incidents)

Ways to Connect

• Link-Out Option
  • This requires very little work on both sides. Adding links in your ITSM or originating system taking users straight into the Tangoe portal. Approvals would happen through Tangoe. Please ask your project manager for a demo to see how the Tangoe Platform works if this has never been demonstrated.
• Build-Out Option
  • This requires a lot more effort on both sides with the majority of the workload on the client-side. Each activity on our side requires specific payloads and suggested lookups. Approvals will typically happen on the client side.

NOTE: (Tangoe does not offer a plugin or app to leverage Tangoe Mobile. We only offer a robust set of APIs for clients to build and leverage the Tangoe Mobile platform from their ITSM. )

PROCUREMENT AND CHANGE MANAGEMENT

A client can leverage procurement and change management in two ways.

Option 1 – Link-Out

The first option is to simply use links provided by Tangoe. This option requires little development on both sides. Linking out from the users ITSM or originating system to that particular Activity such as Device Upgrade inside the Tangoe Portal. This happens seamlessly using SSO (single-sign-on). With this option, it should be noted that approvals will happen in Tangoe. We store each person's approver in their person record table. We leverage the HR feed provided by the customer to keep this approver id up to date. Approvers are sent an email with an Approve or Deny link which allows them to view more details about the request with the option to leave comments.

For the reverse side of this, if the client wants to have a record of these activities, Tangoe can PUSH this data to your system via a custom workflow or you could PULL the data using our API. See Updates to Client System for details on how to get updates.

Figure 1: Link out process flow

Figure 2: Example Link out from ServiceNow to Tangoe

Figure 3: Tangoe portal

Option 2 – Build-Out

The second option is an API integrated approach where the client wants the user experience and approvals to happen inside their ITSM system such as ServiceNow. See Figure 4 below for a process flow.

Figure 4: Build out process flow

Tangoes Mobile API is a standard web resource-based API with JSON request and response payloads. Authentication is a token-based header that we give clients to make API calls and pull data from our system. This option requires the client to replicate the functionality of the Tangoe portal in their own system by creating forms that users will populate and submit via the API. You will have access to 25+ of Tangoe Mobile’s top mobility activity types.

A request Activity form such as New Line (a new line of service with a new device) will need to be built by the client making API calls to Tangoe to display the correct scoped data to the user. Each Activity in our catalog has required attributes in their respected payloads and will require suggested lookups to pull in the correct IDs for each of those attributes. When building out the forms, we recommend a particular hierarchy as described in this link here.

To note, if your catalog of devices, plans, and features are limited, you can hard code these values and not worry about making all the suggested lookups for the IDs. Tangoe would supply the IDs to populate on your end. We also recommend storing these values in a data table rather than having to make a code change later on.

Next, you will want to take the data that has been captured and send it back to Tangoe via the API to create the Activity. On the other side of this, as we process those Activities either by bot automation or manually, we can send updates via a reverse API webhook. This happens by exposing an API endpoint and giving credentials to Tangoe that would allow us to send data back and close Activities once they are completed on our side. An example payload that Tangoe can capture and send back upon closure of any Activity is shown in Figure 5 below. For more details on getting updates by either a push or pull, visit Updates to Client System.

Our system is pretty flexible on what we can send. If you don’t allow external vendors to send data into your system you can PULL the status of those tickets based on the data that we provide whenever you create the tickets. After ticket creation, you will receive a unique ticket id that you can look at the status of those tickets through the API.

Figure 5: Example payload of what Tangoe can send back to update the client system on closed/complete

ritm_number: “1234”,
state": "3",
worknotes: Your mobility request has been completed. The details are as follows:
Assigned to:
Ticket Number:
Submitted Date/Time:
Requestor name/email:
Ticket Type:
User Name:
Wireless Carrier:
Phone Number:
Device:
Plan:
Plan Costs:
Area Code:
Preferred Address:
Shipping Address:
Order Tracking URL:
Port/TOL information:
Existing Phone Number:
Account Number:
Name:
Notes: